demo/pkg/subgraphs/student/.cursor/rules/plugin-development.mdc (1)

43-43: Clarify guidance on build verification.

Line 43 states "Don't verify if the binary was created. The build command will take care of that," but this is ambiguous. Developers may be uncertain whether this means:

• The build will silently succeed even if the binary is missing
• Errors will be visible in build output
• They should trust the exit code

Consider clarifying the intent:

-6. Your job is done after successfully building the plugin. Don't verify if the binary was created. The build command will take care of that.
+6. Your job is done after the build completes successfully. The build command will fail with an error if the binary cannot be created, so you can trust the exit code.

cli/student/.cursor/rules/plugin-development.mdc (1)

1-85: Consider consolidating duplicate documentation.

Both .cursor/rules/plugin-development.mdc files (this one and demo/pkg/subgraphs/student/.cursor/rules/plugin-development.mdc) contain identical content except for the directory paths. This duplication creates a maintenance burden: if the guidance needs to be updated, both files must be modified in sync to avoid divergence.

Consider options:

1. Move to a shared location: Store a single source-of-truth guide in a central docs directory and reference it from both .cursor/rules/ locations via symlink or inclusion.
2. Auto-generate: If these files are generated by a CLI command, ensure the generation logic produces consistent output across multiple plugin directories.
3. Document the policy: If duplication is intentional (e.g., each plugin directory is self-contained), add a comment at the top of each file stating "This file is intentionally duplicated in [other locations] for local IDE guidance. Keep in sync when updating."

cli/student/Makefile (1)

2-2: Add standard phony targets "all" and "clean", and avoid shadowing "make" target.

The Makefile should declare the standard phony targets "all" and "clean" per convention. Additionally, renaming the "make" target (line 7) to something like "default" or "setup" would avoid shadowing the built-in Make command. Consider:

-.PHONY: build test generate install-wgc
+.PHONY: all build test generate install-wgc clean

+all: build
+
+clean:
+	rm -rf dist/ node_modules/
+
-make: build
+default: build

cli/student/README.md (1)

23-34: Address markdown lint and align docs with TS/Bun scaffolding.

• Add a language to fenced code (MD040).
• Paths/instructions appear Go‑only; include TS/Bun equivalents and correct folder to cli/student/ if applicable.

-   ```
+   ```text
     plugins/student/
@@
-    │   ├── main.go           # Main plugin implementation
-    │   ├── main_test.go      # Tests for the plugin
-    │   └── schema.graphql    # GraphQL schema defining the API
+    │   ├── main.go / plugin.ts  # Go or TS implementation
+    │   ├── *_test.go / *.spec.ts # Tests
+    │   └── schema.graphql       # GraphQL schema
@@
-    └── bin/                  # Compiled binaries (created during build)
-        └── plugin            # The compiled plugin binary
+    └── bin/                  # Build output
+        └── plugin / dist     # Go binary or TS build artifacts

Also extend “Customizing” with TS/Bun:

• TS: bun install, bun run build, run client/server examples.
• Go: make generate && make test && make build.

Also applies to: 38-41

demo/pkg/subgraphs/student/src/schema.graphql (1)

1-17: Confirm composition intent for Query.

If this schema composes with other subgraphs, prefer extend type Query to avoid redefining the root. If it’s a standalone demo, current form is fine. Consider adding federation directives later if World becomes an entity.

demo/pkg/subgraphs/student/src/plugin.ts (2)

3-6: Remove unused imports

path and fileURLToPath aren’t used.

-import * as path from 'path';
-import { fileURLToPath } from 'url';

---

63-64: Nit: prefer template strings

Readability/consistency.

-    world.setId(`world-`+counter);
-    world.setName(`Hello There, `+ name);
+    world.setId(`world-${counter}`);
+    world.setName(`Hello There, ${name}`);

demo/pkg/subgraphs/student/Makefile (1)

2-19: Make the default target build, add all/clean, and drop the “make” alias

Current first target (install-wgc) runs on plain make. Add an all alias, set the default goal, provide clean, and avoid global installs where possible.

-.PHONY: build test generate install-wgc
+.PHONY: all build test generate publish install-wgc clean
+.DEFAULT_GOAL := build
 
 install-wgc:
-	@which wgc > /dev/null 2>&1 || npm install -g wgc@latest
+	@command -v wgc >/dev/null 2>&1 || npx -y wgc@latest --version >/dev/null
 
-make: build
+all: build
 
 test: install-wgc
 	wgc router plugin test .
 
 generate: install-wgc
 	wgc router plugin generate .
 
-publish: generate
+publish: build
 	wgc router plugin publish .
 
 build: install-wgc
 	wgc router plugin build . --debug
+
+clean:
+	@rm -rf dist .wgc || true

Run checkmake again to confirm warnings are resolved.

cli/student/src/plugin.ts (6)

3-6: Clean up unused imports and derived variables

path, fileURLToPath, __filename, __dirname are unused; removing them also satisfies the import-order lint failures.

-import * as grpc from '@grpc/grpc-js';
-import * as path from 'path';
-import { fileURLToPath } from 'url';
+import * as grpc from '@grpc/grpc-js';
@@
-// Get the directory of the current module
-const __filename = fileURLToPath(import.meta.url);
-const __dirname = path.dirname(__filename);

Also applies to: 18-21

---

26-41: Logger doesn’t log — write to stderr to avoid polluting stdout handshake

Ensure logs go to stderr; keep stdout reserved for the go-plugin handshake line.

 class Logger {
   log(level: string, message: string): void {
     const timestamp = new Date().toISOString();
+    // Emit to stderr to not interfere with go-plugin stdout handshake
+    console.error(`[${timestamp}] [${level}] ${message}`);
   }

---

55-56: Remove placeholder text in greeting

Looks accidental.

-    world.setName(`Hello Thereeeee 17 17 17 17 17 17 17 17 1777 `+ name);
+    world.setName(`Hello There, ${name}`);

---

96-99: Fix typo and surface startup errors

s/serverL/server/ and ensure the message is visible.

-  logger.error(`Failed to start serverL `+ error.message);
+  logger.error(`Failed to start server: ${error.message}`);

---

3-3: Satisfy lint: prefer node: specifier and import ordering (if you keep these imports)

If you decide to keep path/url, follow the lints: use node:path default import and place @grpc/grpc-js after url.

-import * as grpc from '@grpc/grpc-js';
-import * as path from 'path';
-import { fileURLToPath } from 'url';
+import { fileURLToPath } from 'node:url';
+import path from 'node:path';
+import * as grpc from '@grpc/grpc-js';

Also applies to: 4-4

---

60-62: Use template strings for readability

-    logger.info("Returning world: id="+world.getId()+", name="+world.getName()+", counter="+counter);
+    logger.info(`Returning world: id=${world.getId()}, name=${world.getName()}, counter=${counter}`);

cli/src/commands/router/commands/plugin/templates/goplugin.ts (1)

15-19: Prefer Register{serviceName}Server for consistency with tests and idiomatic gRPC

Use the generated registrar helper instead of RegisterService with ServiceDesc.

-  pl, err := routerplugin.NewRouterPlugin(func(s *grpc.Server) {
-    s.RegisterService(&service.{serviceName}_ServiceDesc, &{serviceName}{
-      nextID: 1,
-    })
-  }, routerplugin.WithTracing())
+  pl, err := routerplugin.NewRouterPlugin(func(s *grpc.Server) {
+    service.Register{serviceName}Server(s, &{serviceName}{
+      nextID: 1,
+    })
+  }, routerplugin.WithTracing())

cli/src/commands/router/commands/plugin/commands/init.ts (1)

85-97: Minor: add missing break and keep cases symmetrical

Not strictly required (last case), but keeps future edits safe.

         case 'ts': {
           await writeFile(resolve(srcDir, 'plugin.ts'), pupa(TsTemplates.pluginTs, { serviceName }));
           await writeFile(resolve(srcDir, 'client.ts'), pupa(TsTemplates.clientTs, { serviceName }));
           await writeFile(resolve(tempDir, 'package.json'), pupa(TsTemplates.packageJson, { serviceName }));
+          break;
         }

cli/src/commands/router/commands/plugin/templates/tsplugin.ts (2)

97-104: Template polish: overly noisy greeting.

The hardcoded “Hello Thereeeee 17…” looks accidental. Keep the template clean and predictable.

-    world.setName(`Hello Thereeeee 17 17 17 17 17 17 17 17 1777 `+ name);
+    world.setName(`Hello ${name}`);

---

146-167: package.json template: versions reasonable; consider pinning @types/bun.

To improve reproducibility, avoid "latest" on @types/bun.

-    "@types/bun": "latest",
+    "@types/bun": "^1.1.10",

cli/src/commands/router/commands/plugin/toolchain.ts (2)

248-296: Tool install checks always include Go; make language-aware to avoid unnecessary installs for TS-only builds.

TS path only needs protoc; prompting to install Go increases friction.

• Accept a language argument in checkAndInstallTools and conditionally verify/install Go toolchain only when language === 'go'.
• Alternatively, split into checkAndInstallGoTools() and checkAndInstallCommonTools().

---

456-485: TS codegen path: robust; minor Windows chmod caveat.

Good validation and plugin wiring. Note chmod on Windows is a no-op; you can guard by process.platform !== 'win32' to avoid confusing logs.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

cli/src/commands/router/commands/plugin/toolchain.ts (1)

23-29: Critical: Windows platform name mismatch breaks TS host builds.

getHostPlatform('ts') returns bun-${os.platform()}-${arch}, but on Windows os.platform() returns 'win32', not 'windows'. The ALL_BUN_PLATFORM_MAPPINGS at lines 43-51 only has keys like 'bun-windows-x64', so Windows host builds will fail with "Unsupported platform" when normalizePlatforms tries to default to the host platform.

Apply this diff to normalize the platform name:

 export function getHostPlatform(language: string) {
-  const basePlatform = `${os.platform()}-${getOSArch(language)}`;
+  const nodePlatform = os.platform();
+  const normalizedOS = nodePlatform === 'win32' ? 'windows' : nodePlatform;
+  const basePlatform = `${normalizedOS}-${getOSArch(language)}`;
   if (language === 'ts') {
     return `bun-${basePlatform}`;
   }
   return basePlatform;
 }

cli/src/commands/router/commands/plugin/toolchain.ts (2)

656-656: Add .exe suffix and use path join for Windows binary output.

Windows executables require the .exe extension, and the outfile path should use join() for cross-platform safety rather than string concatenation.

Apply this diff:

-      const binaryName = `${platform}_${arch}`;
+      const binaryName = `${platform}_${arch}${platform === 'windows' ? '.exe' : ''}`;
       
       spinner.text = `Building ${originalPlatformArch}...`;
       
       if (debug) {
         const debugScript = resolve(pluginDir, join('bin', originalPlatformArch));
         await writeFile(debugScript, pupa(TsTemplates.debugBuild, {}));
         await chmod(debugScript, 0o755);
       } else {
         const flags = [
           'build',
           'src/plugin.ts',
           '--compile',
           '--outfile',
-          `bin/${binaryName}`,
+          join('bin', binaryName),
           `--target=${originalPlatformArch}`,
         ];

Also applies to: 670-670

---

614-614: Consider using bun x tsc to ensure TypeScript runs through Bun.

Running bun tsc directly may respect the #!/usr/bin/env node shebang in the TypeScript binary, potentially invoking the system Node.js instead of Bun's runtime. Using bun x tsc ensures TypeScript is executed through Bun's package runner.

Apply this diff:

-  await execa(bunPath, ['tsc', '--noEmit'], {
+  await execa(bunPath, ['x', 'tsc', '--noEmit'], {
     cwd: pluginDir,
     stdout: 'inherit',
     stderr: 'inherit',
     env,
   });

cli/src/commands/router/commands/plugin/commands/generate.ts (1)

97-97: Make guidance message language-aware.

The success message references src/main.go, which is Go-specific. TypeScript plugins use src/plugin.ts, so this guidance will confuse TS plugin developers.

Apply this diff to tailor the message by language:

+      const implFile = language === 'ts' ? 'src/plugin.ts' : 'src/main.go';
+
       console.log('');
       console.log(
-        `  Now you can modify your implementation in src/main.go, then when you're ready to publish, run ${pc.bold('wgc router plugin publish')}.`,
+        `  Now you can modify your implementation in ${implFile}, then when you're ready to publish, run ${pc.bold('wgc router plugin publish')}.`,
       );

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: Noroth
Repo: wundergraph/cosmo PR: 2290
File: protographic/src/sdl-to-proto-visitor.ts:1350-1390
Timestamp: 2025-10-27T09:45:41.622Z
Learning: In protographic/src/sdl-to-proto-visitor.ts, resolver-related messages (created by `createResolverRequestMessage` and `createResolverResponseMessage`) are special messages that should not be tracked in the proto lock file, unlike other message types.

Learnt from: Noroth
Repo: wundergraph/cosmo PR: 2151
File: protographic/src/sdl-to-proto-visitor.ts:0-0
Timestamp: 2025-08-20T10:38:49.191Z
Learning: Inline `extend google.protobuf.FieldOptions` declarations in proto3 files work correctly with protoc, despite theoretical concerns about proto3 compatibility with extension declarations.

router-tests/router_plugin_test.go (1)

69-69: Consider adding a similar restart test for the courses subgraph.

The rename to "Should restart plugin if it exits for projects" is more specific and accurate. Since you've added courses integration tests below, consider adding a parallel restart test for the courses plugin to ensure its restart behavior is also validated.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: SkArchon
Repo: wundergraph/cosmo PR: 2252
File: router-tests/telemetry/telemetry_test.go:9684-9693
Timestamp: 2025-10-01T20:39:16.113Z
Learning: Repo preference: In router-tests/telemetry/telemetry_test.go, keep strict > 0 assertions for request.operation.*Time (parsingTime, normalizationTime, validationTime, planningTime) in telemetry-related tests; do not relax to >= 0 unless CI flakiness is observed.

Learnt from: SkArchon
Repo: wundergraph/cosmo PR: 2172
File: router/core/graph_server.go:0-0
Timestamp: 2025-09-17T20:55:39.456Z
Learning: The Initialize method in router/internal/retrytransport/manager.go has been updated to properly handle feature-flag-only subgraphs by collecting subgraphs from both routerConfig.GetSubgraphs() and routerConfig.FeatureFlagConfigs.ConfigByFeatureFlagName, ensuring all subgraphs receive retry configuration.

Learnt from: endigma
Repo: wundergraph/cosmo PR: 2141
File: router-tests/http_subscriptions_test.go:17-55
Timestamp: 2025-08-28T09:17:49.477Z
Learning: The Cosmo router uses a custom, intentionally rigid multipart implementation for GraphQL subscriptions. The multipart parsing in test files should remain strict and not be made more tolerant, as this rigidity is by design.

Learnt from: StarpTech
Repo: wundergraph/cosmo PR: 2157
File: router-tests/go.mod:16-16
Timestamp: 2025-08-20T22:13:25.222Z
Learning: github.com/mark3labs/mcp-go v0.38.0 has regressions and should not be used in the wundergraph/cosmo project. v0.36.0 is the stable version that should be used across router-tests and other modules.

cli/src/commands/router/commands/plugin/commands/init.ts (1)

86-86: Remove unnecessary non-null assertion.

goModulePath is defined as a string constant on line 71, so the ! operator is unnecessary.

Apply this diff:

-          protoOptions.push(getGoModulePathProtoOption(goModulePath!));
+          protoOptions.push(getGoModulePathProtoOption(goModulePath));

router-tests/router_plugin_test.go (2)

106-141: Courses restart test mirrors projects behavior appropriately

The new “courses” restart test is a solid companion to the projects one: it kills the courses service, waits for the plugin process exited log, and then asserts a successful courses { id } response via require.EventuallyWithT. Timeouts and polling intervals are reasonable for CI, and the configuration matches the existing plugin tests.

If you see this becoming flaky or slow in CI, consider tightening the Eventually windows once you’ve observed typical restart timings.

---

363-377: Table-driven courses queries integrate cleanly into existing plugin tests

The added table entries for simple courses listing, single-course lookup, and “employee teaching a course” nicely cover the new demo surface and reuse the existing table-driven harness. The expected JSON bodies are consistent and will strongly assert correct wiring of the new subgraph/plugin.

If more courses-related cases accumulate, consider grouping them (e.g., by prefixing name with courses:) to make it easier to skim which tests exercise which subgraph.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: endigma
Repo: wundergraph/cosmo PR: 2141
File: router-tests/http_subscriptions_test.go:17-55
Timestamp: 2025-08-28T09:17:49.477Z
Learning: The Cosmo router uses a custom, intentionally rigid multipart implementation for GraphQL subscriptions. The multipart parsing in test files should remain strict and not be made more tolerant, as this rigidity is by design.

Learnt from: SkArchon
Repo: wundergraph/cosmo PR: 2252
File: router-tests/telemetry/telemetry_test.go:9684-9693
Timestamp: 2025-10-01T20:39:16.113Z
Learning: Repo preference: In router-tests/telemetry/telemetry_test.go, keep strict > 0 assertions for request.operation.*Time (parsingTime, normalizationTime, validationTime, planningTime) in telemetry-related tests; do not relax to >= 0 unless CI flakiness is observed.

Learnt from: SkArchon
Repo: wundergraph/cosmo PR: 2172
File: router/core/graph_server.go:0-0
Timestamp: 2025-09-17T20:55:39.456Z
Learning: The Initialize method in router/internal/retrytransport/manager.go has been updated to properly handle feature-flag-only subgraphs by collecting subgraphs from both routerConfig.GetSubgraphs() and routerConfig.FeatureFlagConfigs.ConfigByFeatureFlagName, ensuring all subgraphs receive retry configuration.

Learnt from: StarpTech
Repo: wundergraph/cosmo PR: 2157
File: router-tests/go.mod:16-16
Timestamp: 2025-08-20T22:13:25.222Z
Learning: github.com/mark3labs/mcp-go v0.38.0 has regressions and should not be used in the wundergraph/cosmo project. v0.36.0 is the stable version that should be used across router-tests and other modules.

Learnt from: endigma
Repo: wundergraph/cosmo PR: 2141
File: router-tests/http_subscriptions_test.go:17-55
Timestamp: 2025-08-28T09:17:49.477Z
Learning: The Cosmo router uses a custom, intentionally rigid multipart implementation for GraphQL subscriptions. The multipart parsing in test files should remain strict and not be made more tolerant, as this rigidity is by design.

cli/src/commands/router/commands/plugin/commands/init.ts (1)

86-86: Remove unnecessary non-null assertion.

The goModulePath variable is defined as a string literal at line 71 and is never null or undefined, so the non-null assertion operator ! is unnecessary.

Apply this diff:

-          protoOptions.push(getGoModulePathProtoOption(goModulePath!));
+          protoOptions.push(getGoModulePathProtoOption(goModulePath));

demo/pkg/subgraphs/courses/src/plugin.ts (5)

1-30: Keep demo package.json in sync with gRPC/protobuf dependencies

This module (and plugin-server.ts) rely on @grpc/grpc-js, google-protobuf (wrappers), grpc-health-check, and the generated service_* modules. Please ensure demo/pkg/subgraphs/courses/package.json declares these as dependencies so Bun can build and run the plugin reliably (especially in CI/Docker).

---

32-62: ID generator is concurrency-safe but more complex than needed

Using SharedArrayBuffer + Atomics is robust, but given handlers execute on a single JS thread in Bun/Node, a simple module-level counter (e.g. let nextId = 1000;) would be enough and easier to reason about. Consider simplifying if you don’t need true cross-thread atomics.

---

215-283: Clarify intent of queryThrowErrorCourses and error handling

queryThrowErrorCourses throws directly from the handler and never calls the callback. Depending on @grpc/grpc-js behavior, this may crash the Bun/Node process rather than just surfacing an application error.

If the goal is to simulate a failing RPC while keeping the plugin alive, prefer callback(new Error('...')). If the goal is explicitly to crash the plugin for router resilience tests, consider documenting that intent here so future readers don’t “fix” it unintentionally.

---

285-341: Mutations accept invalid input without signaling errors

Both mutationAddCourse and mutationAddLesson happily proceed with whatever IDs/titles they receive (e.g. unknown courseId, empty title), silently creating partial or dangling data.

That’s fine for a demo, but if you plan to reuse this as a template, consider adding minimal validation (and returning a gRPC error) so downstream behavior is more predictable.

---

410-419: Separate plugin implementation from server startup to avoid import side effects

Right now plugin.ts both exports pluginImplementation and, at module load, instantiates PluginServer, registers the service, and calls .serve(). That’s convenient for the binary entrypoint, but it means any import of this module (e.g. unit tests) will also start a gRPC server as a side effect.

Consider splitting this into:

• plugin.ts: exports only pluginImplementation.
• main.ts (or similar): imports pluginImplementation + PluginServer, wires the service, and calls serve().

This keeps tests and tooling free of unexpected server startup while still giving you a clean entrypoint for the Bun-built plugin binary.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: endigma
Repo: wundergraph/cosmo PR: 2141
File: router-tests/http_subscriptions_test.go:17-55
Timestamp: 2025-08-28T09:17:49.477Z
Learning: The Cosmo router uses a custom, intentionally rigid multipart implementation for GraphQL subscriptions. The multipart parsing in test files should remain strict and not be made more tolerant, as this rigidity is by design.

cli/src/commands/router/commands/plugin/toolchain.ts (3)

31-52: TS binary build: use joined outfile path and .exe on Windows targets

buildTsBinaries mostly looks good, but there are a couple of correctness/robustness gaps:

• Outfile path is passed as a plain string: '--outfile', `bin/${binaryName}` rather than join(binDir, binaryName). This is brittle and bypasses your earlier binDir calculation.
• Windows targets currently output windows_amd64 without a .exe extension. Depending on how the router spawns the binary, this can make the artifact unusable on Windows hosts.

You can tighten this up with:

const [platform, arch] = platformArch.split('-');
if (!platform || !arch) {
  throw new Error(
    `Invalid platform-architecture format: ${originalPlatformArch}. Use format like 'bun-darwin-arm64'`,
  );
}

const binaryName = `${platform}_${arch}${platform === 'windows' ? '.exe' : ''}`;
const outfile = join(binDir, binaryName);
…
const flags = [
  'build',
  'src/plugin.ts',
  '--compile',
  '--outfile',
  outfile,
  `--target=${originalPlatformArch}`,
];

This keeps naming consistent and avoids path bugs across OSes.

Also applies to: 35-41, 653-671, 672-711

---

22-29: Windows TS host platform mismatch (bun-win32-x64 vs bun-windows-x64)

getHostPlatform('ts') builds bun-${os.platform()}-${getOSArch('ts')}. On Windows this yields bun-win32-x64, but:

• ALL_BUN_PLATFORMS and ALL_BUN_PLATFORM_MAPPINGS use bun-windows-x64.
• normalizePlatforms uses getHostPlatform(language) as the default platform.

Result: normalizePlatforms([], false, 'ts') on Windows will produce ['bun-win32-x64'], which has no mapping and later fails in buildTsBinaries.

Normalize the OS name the same way everywhere, e.g.:

export function getHostPlatform(language: string) {
  const nodePlatform = os.platform();
  const normalizedOS = nodePlatform === 'win32' ? 'windows' : nodePlatform;
  const basePlatform = `${normalizedOS}-${getOSArch(language)}`;
  if (language === 'ts') {
    return `bun-${basePlatform}`;
  }
  return basePlatform;
}

This keeps TS host defaults consistent with ALL_BUN_PLATFORMS and the Bun mapping table.

Also applies to: 132-142, 761-783, 785-797

---

633-649: Run TS type-checks via bun x tsc --noEmit instead of bun tsc

typeCheckTs currently does:

await execa(bunPath, ['tsc', '--noEmit'], { ... });

This invokes the tsc script directly, which still uses the Node shebang and can hit the system Node (or fail if Node is missing/too old), undermining the Bun‑only toolchain goal.

Prefer Bun’s runner to execute the package binary:

await execa(bunPath, ['x', 'tsc', '--noEmit'], {
  cwd: pluginDir,
  stdout: 'inherit',
  stderr: 'inherit',
  env,
});

This ensures the TypeScript CLI comes from the project dependencies and runs under Bun.

Is `bun x tsc --noEmit` the recommended way to run TypeScript type-checks under Bun without relying on a global Node installation?

cli/src/commands/router/commands/plugin/commands/generate.ts (1)

38-45: Make success messaging and details language‑aware (Go vs TS)

You already detect language and branch logic, but the user‑facing output is still Go‑specific:

• Guidance always says: “modify your implementation in src/main.go…”, which is wrong for TS plugins (src/plugin.ts).
• Details don’t show the language at all, and protoOptions is the only extra field.

Consider:

• Adding language to the details map.
• Picking an implementation hint file per language:

const implHintFile = language === 'ts' ? 'src/plugin.ts' : 'src/main.go';

const details: Record<string, string> = {
  output: pluginDir,
  time: formattedTime,
  language,
  protoOptions: protoOptionsSummary,
};

…

console.log(
  `  Now you can modify your implementation in ${implHintFile}, then when you're ready to publish, run ${pc.bold(
    'wgc router plugin publish',
  )}.`,
);

This clarifies next steps for TS users without affecting Go.

Also applies to: 76-82, 95-98

scripts/install-proto-tools.sh (1)

9-12: LANGUAGE under set -u can fail with an unhelpful “unbound variable” error

With set -u, LANGUAGE="${LANGUAGE}" will abort the script if LANGUAGE is unset (e.g. when someone curls the script manually), before reaching the nice Unsupported language: $LANGUAGE. Must be 'go' or 'ts'. error.

Consider guarding or defaulting LANGUAGE explicitly so failures are clearer:

# Example: require LANGUAGE with a helpful message
: "${LANGUAGE:?LANGUAGE must be set to 'go' or 'ts'}"

or provide a sane default like LANGUAGE="${LANGUAGE:-go}" if that matches your intended UX.

Also applies to: 236-249

cli/src/commands/router/commands/plugin/commands/test.ts (1)

34-41: Simplify test failure handling; result.failed is never true with default execa options

Inside the inner test try you do:

let failed = false;
switch (language) {
  case 'go': {
    const result = await runGoTests(srcDir, spinner, false);
    failed = result.failed;
    break;
  }
  case 'ts': {
    const result = await runTsTests(pluginDir, spinner);
    failed = result.failed;
    break;
  }
}
…
const title = failed ? 'Tests failed!' : 'Tests completed successfully!';

But with execa’s default reject: true, a non‑zero exit throws instead of returning { failed: true }, so:

• On success: failed stays false, title = “Tests completed successfully!”
• On failure: control jumps to the catch block and this code path is never reached.

You can drop failed entirely and treat reaching the try block as success:

await (language === 'go'
  ? runGoTests(srcDir, spinner, false)
  : runTsTests(pluginDir, spinner));

const title = 'Tests completed successfully!';
// render success tree

and rely on the existing catch to render the failure tree.

Also applies to: 67-80

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: Noroth
Repo: wundergraph/cosmo PR: 2151
File: protographic/src/sdl-to-proto-visitor.ts:0-0
Timestamp: 2025-08-20T10:38:49.191Z
Learning: Inline `extend google.protobuf.FieldOptions` declarations in proto3 files work correctly with protoc, despite theoretical concerns about proto3 compatibility with extension declarations.

cli/src/commands/router/commands/plugin/commands/generate.ts (1)

97-97: Make guidance message language-aware.

The success message still references src/main.go for all languages, but TS plugins use src/plugin.ts. Tailor the message by language.

Apply:

+      const implHintFile = language === 'ts' ? 'src/plugin.ts' : 'src/main.go';
       console.log(
-        `  Now you can modify your implementation in src/main.go, then when you're ready to publish, run ${pc.bold('wgc router plugin publish')}.`,
+        `  Now you can modify your implementation in ${implHintFile}, then when you're ready to publish, run ${pc.bold('wgc router plugin publish')}.`,
       );

cli/src/commands/router/commands/plugin/toolchain.ts (2)

23-29: Windows host platform mismatch breaks TS builds.

getHostPlatform('ts') returns bun-win32-x64 (from os.platform()), but ALL_BUN_PLATFORM_MAPPINGS keys use bun-windows-x64. This causes platform normalization to fail on Windows.

Apply:

 export function getHostPlatform(language: string) {
+  const nodePlatform = os.platform();
+  const normalizedOS = nodePlatform === 'win32' ? 'windows' : nodePlatform;
-  const basePlatform = `${os.platform()}-${getOSArch(language)}`;
+  const basePlatform = `${normalizedOS}-${getOSArch(language)}`;
   if (language === 'ts') {
     return `bun-${basePlatform}`;
   }
   return basePlatform;
 }

---

736-750: Add .exe extension for Windows and use safer path construction.

Two issues remain from past review:

1. Windows binaries need .exe extension
2. Output path should use join() instead of string concatenation

Apply:

-      const binaryName = `${platform}_${arch}`;
+      const binaryName = `${platform}_${arch}${platform === 'windows' ? '.exe' : ''}`;
@@
       const flags = [
         'build',
         'src/plugin.ts',
         '--compile',
         '--outfile',
-        `bin/${binaryName}`,
+        join('bin', binaryName),
         `--target=${originalPlatformArch}`,
       ];

scripts/install-proto-tools.sh (1)

13-13: Clarify LANGUAGE variable assignment or add validation.

Line 13 assigns LANGUAGE="${LANGUAGE}", which is a tautology—if LANGUAGE is unset, it remains empty. While the case statement at line 276 correctly errors out on empty LANGUAGE, the assignment at line 13 suggests a default will be applied, which is misleading. Either remove the assignment and rely on the case-statement error handling, or add a comment explaining that LANGUAGE must be explicitly provided via the environment.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: Noroth
Repo: wundergraph/cosmo PR: 2151
File: protographic/src/sdl-to-proto-visitor.ts:0-0
Timestamp: 2025-08-20T10:38:49.191Z
Learning: Inline `extend google.protobuf.FieldOptions` declarations in proto3 files work correctly with protoc, despite theoretical concerns about proto3 compatibility with extension declarations.